RFC: feat: frr extension #821
Conversation
| entrypoint: /usr/lib/frr/frrinit.sh | ||
| mounts: | ||
| # libs | ||
| - source: /lib |
There was a problem hiding this comment.
extension services can be thought as simple containers running in the privileged context, so they could just simply bring all "tools" within the image, they don't have to link anything from the host.
in fact, you should be able to docker run the extension service (by copying the content out to /).
so unless strictly required, one can simply include any container image as an extension service.
|
Is it too hard to implement FRR via e.g. https://github.com/osrg/gobgp and make it part of core Talos? |
I think this is an implementation using gobgpd https://github.com/vitaly-zverev/frr-talos-extension/tree/master |
|
It is not easy at all and will provide less important functionality, with more problems. Firstly, GoBGP doesn't support BFD, and moreover, there isn't a single decent standalone implementation of BFD (and in my view, BFD should be implemented in a runtime-less language). Secondly, GoBGP only handles BGP, whilst FRR supports a far greater number of protocols. Moreover, GoBGP can't install routes into the kernel at all. By the authors, you're meant to use Zebra from FRR for that, but in practice, it doesn't work. Even if it does, it's still maximally flimsy, and using it is more trouble than it's worth. FRR is far more popular and develops more quickly, but it's a bit legacy, that's true. As mentioned above, it can't be built without vtysh, and historically, it's managed via commands. But not long ago, mgmtd was added, which even supports atomic configuration updates with rollbacks, and later a protobuf protocol was introduced. Even so, it seems the primary configuration method remains commands. Other options include Holo, BIRD, and OpenBGPD, but none of them can replace FRR. Accordingly, it turns out that the most sensible and straightforward option is FRR. Additionally, integrating GoBGP into Talos at the MachineConfig level or similar shifts some responsibility from the user to Talos, which isn't ideal. For example, you could accidentally omit some functionality, creating an artificial limitation. Whereas with FRR, the user controls everything, so there are definitely no limitations. |
|
This PR is stale because it has been open 45 days with no activity. |
3 participants
This PR adds FRR as an extension, running as an extension service.
It is still very draft, at least, because I need to clarify some points, that's why it is an RFC PR.
First, it seems to me that at least ncurses, readline, libmd, libbsd should be added to pkgs, since these are fundamental libraries. But libyang is unlikely to be used anywhere except frr.
On the other hand, I don't understand how to package anything normally in this strange build system, so I decided to link everything as statically as possible.
Another idea I had was to build some minimalistic distribution locally completely from source, wolfi or something else. Well, I couldn't figure out how to build wolfi from source, and other distributions didn't really come to mind.
Another problem - readline publishes only major-minor tarballs, and patch-level fixes are literally pushed as literally patches. It is unclear how to integrate this with renovate, and in general it is not clear to me how renovate works here.
Next, another problem - regarding ncruses. Ncurses needs terminfo files to work, if they are missing or if there is something wrong with them, then ncurses simply will not work. Here, for example, you can use vtysh via nsenter, but is this functionality necessary? In theory, you can compile frr without vtysh, but in practice, probably not?